feat(agentex): run Slack turns as the invoking user, and the flow to link them - #410

#412)

## What

The last piece of the identity-link flow. #409 added the storage, #410
the gateway
wiring and the link routes — but nothing ever handed a user a link, so
the only way
in was a dev script. Now an unlinked mention offers one.

When a turn is **not** running as a person — unlinked, or linked with a
credential we
can't use (expired session, undecryptable ciphertext) — the gateway:

```
1. mint (or reuse) a nonce carrying the Slack identity Slack's HMAC just verified,
   plus the message that triggered it
2. conversations.open -> chat.postMessage   DM that user the link
3. chat.postEphemeral                       tell them in-channel a DM is waiting
```

A dead credential gets the same offer as no credential, since re-linking
is the fix
for both.

## The link is DMed and never posted in a channel

This is the part worth reviewing closely. The nonce is a **bearer
token**: whoever
opens it gets linked to that Slack identity by signing in as themselves.
Posted in a
channel, the first person to read it could bind someone else's Slack
identity to
their own SGP account.

So when `conversations.open` or the DM fails, we log and stop — there is
no fallback
to anywhere visible. A test asserts the token never appears in any
payload addressed
to the origin channel, and another that a failed DM leaks it nowhere.

## Best-effort by construction

The turn is already proceeding (as the shared bot, or being refused
immediately
after), and nothing in the offer path may change that. A Redis outage, a
missing
scope, a closed DM — all end in "no offer" and an unaffected turn.

Offers also require `SLACK_GATEWAY_PUBLIC_BASE_URL`. Unset means no
offers at all:
the host must be browser-reachable *and* a sibling subdomain of the SGP
host or the
session cookie never arrives at the callback. A link that cannot work is
worse than
no link.

## Rate limiting, two layers for two problems

- **`claim_send`** (from #410) caps DMs about one live link at 2, so a
re-mention
  re-sends the same link rather than going quiet.
- **A cooldown key** (`SLACK_LINK_OFFER_COOLDOWN_S`, default 1h) stops a
fresh nonce
from re-arming that budget every time the old one expires. Without it, a
persistent
mentioner collects ~12 DMs an hour instead of ~2. It fails **open** on a
Redis
error — never offering is the worse failure, and `claim_send` still
bounds it.

## Email match — shipped OFF

The nonce stops an attacker forging someone else's Slack identity. It
does **not**
stop them forwarding their *own* link: if a victim clicks it while
signed in, the
attacker's Slack identity binds to the victim's SGP account, and from
then on the
attacker's Slack messages run as the victim, with the victim's
integrations. The
confirmation page naming both identities catches a mis-click but reduces
to user
vigilance against a deliberate attempt.

Comparing the Slack account's email against the signed-in SGP account's
closes it.

It ships disabled because it needs the **`users:read.email` Slack scope,
which is not
granted** — verified, `users.lookupByEmail` returns `missing_scope`.
Enable
`IDENTITY_LINK_REQUIRE_EMAIL_MATCH` and the scope together.

⚠️ **The check treats an unreadable email as a MISMATCH, not as
"skip".** So turning
the flag on without the scope refuses every link. That direction is
deliberate:
failing open would silently disable the only defence the moment the
scope lapsed.
Tests pin both directions.

## Not included

**Replaying the stashed turn.** `pending_turn` is recorded for it, but
the
confirmation page still says "ask me again in Slack". Wiring the link
route back into
the gateway is a coupling worth doing on its own, with care that a
replay failure
can't undo a successful link.

## Testing

**15 new unit tests**, aimed at the failure modes rather than the happy
path:

- link offer: the token never reaching the origin channel; a failed DM
leaking it
nowhere; no offer without a public base URL; the send cap acknowledging
in-channel
instead of going silent; the cooldown suppressing before a nonce is even
minted; a
Redis error swallowed; the DM text warning against forwarding;
`pending_turn`
  stashed for a later replay.
- email match: disabled-by-default doesn't call Slack at all; matching
(and
case-insensitive) emails link; a mismatch refuses **and leaves the nonce
intact**,
so a legitimate owner can still use their own link; unreadable Slack
email and
  missing SGP email both fail closed.

Full unit suite: **685 passed**. `ruff` clean.

The 193 local integration errors are the pre-existing
testcontainers/Mongo issue in
files this PR doesn't touch — they reproduce identically on a clean
checkout of main.

## Deploy notes

Nothing here activates on its own:

| Variable | Effect if unset |
|---|---|
| `SLACK_GATEWAY_PUBLIC_BASE_URL` | **no offers are sent at all** |
| `SLACK_LINK_OFFER_COOLDOWN_S` | defaults to 1h |
| `IDENTITY_LINK_REQUIRE_EMAIL_MATCH` | email match skipped (current
state) |

Scopes: `im:write` and `chat:write` are already granted, so DMs and
ephemerals work
today. `users:read.email` is the only addition needed, and only for the
email match.

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- greptile_comment -->

<h3>Greptile Summary</h3>

Adds Slack account-link offers for users whose turns cannot run under a
usable personal identity, with bearer links delivered only through DMs
and an ephemeral channel acknowledgment.
- Adds Slack profile lookup and optional Slack/SGP email matching during
confirmation.
- Adds nonce reuse, delivery limits, and a per-user offer cooldown.
- Adds unit coverage for delivery confidentiality, failure handling,
rate limiting, pending turns, and email matching.

<details><summary><h3>Confidence Score: 4/5</h3></summary>

The failed-delivery cooldown behavior should be fixed before merging
because a transient Slack failure can prevent the user from receiving a
link for an hour.

The gateway records the offer cooldown before attempting DM delivery and
does not undo it on either Slack failure path, causing later mentions to
be suppressed despite no successful offer.

**Files Needing Attention:**
agentex/src/domain/use_cases/slack_gateway_use_case.py
</details>


<details><summary><h3>Important Files Changed</h3></summary>




| Filename | Overview |
|----------|----------|
| agentex/src/domain/use_cases/slack_gateway_use_case.py | Adds the
Slack DM offer flow, profile lookup, cooldown, and ephemeral
acknowledgment; failed DM delivery incorrectly leaves the cooldown
active. |
| agentex/src/api/routes/integrations.py | Adds an explicitly opt-in,
fail-closed email correspondence check before persisting a Slack
identity link. |
| agentex/tests/unit/use_cases/test_slack_gateway_use_case.py | Covers
link confidentiality and major offer outcomes but does not verify that a
failed delivery remains retryable. |
| agentex/tests/unit/api/test_integrations_routes.py | Covers enabled,
disabled, matching, mismatching, and unreadable-email confirmation
behavior. |

</details>


<details><summary><h3>Sequence Diagram</h3></summary>

```mermaid
sequenceDiagram
    participant U as Slack user
    participant G as Slack gateway
    participant R as Redis/nonce service
    participant S as Slack API
    participant I as Link confirmation route
    G->>G: Resolve invoking identity
    alt No usable personal identity
        G->>R: Claim offer cooldown
        G->>R: Create or reuse nonce and claim send
        G->>S: conversations.open
        G->>S: chat.postMessage with bearer link
        G->>S: chat.postEphemeral acknowledgment
        U->>I: Open link and confirm while signed in
        I->>I: Optionally compare Slack and SGP email
        I->>R: Consume nonce and persist identity link
    end
```
</details>

<a
href="https://app.greptile.com/api/ide/cursor?prompt=Greploop%20scaleapi%2Fscale-agentex%20PR%20%23412%3A%20work%20through%20Greptile's%20open%20review%20comments%2C%20then%20keep%20reviewing%20and%20fixing%20until%20it%20comes%20back%20clean%20at%205%2F5%20with%20zero%20unresolved%20comments.%0AStart%20by%20reading%20the%20comments%20off%20the%20PR%20itself.%20On%20GitHub%2C%20use%20paginated%20%60gh%20api%20graphql%60%20to%20query%20%60pullRequest.reviewThreads%60%20with%20each%20thread's%20%60isResolved%60%20value%20and%20inline%20%60comments%60.%20%60gh%20pr%20view%20--comments%60%20only%20includes%20conversation%20comments%2C%20so%20do%20not%20use%20it%20as%20the%20findings%20source.%20They%20are%20not%20listed%20in%20this%20prompt%20on%20purpose%3A%20the%20PR%20is%20current%2C%20a%20pasted%20copy%20would%20not%20be.%20Skip%20anything%20already%20resolved%2C%20and%20if%20you%20judge%20a%20comment%20wrong%2C%20say%20so%20rather%20than%20changing%20code%20to%20satisfy%20it.%0A%0APrefer%20the%20Greptile%20CLI%2C%20which%20reviews%20the%20working%20tree%20with%20no%20push%20and%20no%20CI%20run.%20Fall%20back%20to%20PUSH%20LOOP%20only%20where%20a%20step%20below%20says%20to.%0A1.%20Run%20%60command%20-v%20greptile%60.%20Missing%3A%20go%20to%20PUSH%20LOOP%2C%20and%20pitch%20the%20CLI%20at%20the%20end.%0A2.%20Run%20%60greptile%20whoami%60.%20It%20exits%200%20even%20when%20signed%20out%2C%20so%20read%20the%20output%3A%20if%20it%20says%20%22Not%20signed%20in%22%2C%20ask%20the%20user%20to%20run%20%60greptile%20login%60%20%28it%20opens%20a%20browser%2C%20do%20not%20run%20it%20yourself%29%20and%20go%20to%20PUSH%20LOOP%20with%20no%20pitch.%0A3.%20Look%20for%20%60greploop%2FSKILL.md%60%20under%20%60.agents%2Fskills%2F%60%20or%20%60.claude%2Fskills%2F%60%2C%20both%20in%20the%20repo%20root%20and%20in%20the%20user's%20home%20directory.%20Found%3A%20follow%20that%20skill%2C%20never%20pushing%20between%20rounds%2C%20and%20you%20are%20done.%0A4.%20Missing%3A%20run%20%60greptile%20skills%20list%60.%20If%20it%20fails%20as%20an%20unknown%20command%2C%20this%20CLI%20predates%20the%20skill%2C%20so%20tell%20the%20user%20to%20run%20%60greptile%20update%60%20and%20go%20to%20PUSH%20LOOP%20with%20no%20pitch.%20Otherwise%20ask%20the%20user%20before%20running%20%60greptile%20skills%20install%20greploop%60%2C%20then%20follow%20the%20skill%20it%20writes.%0A%0APUSH%20LOOP%20%28only%20when%20a%20step%20above%20sends%20you%20here%29%3A%0A%0AGREPLOOP%20ENABLED%3A%20After%20fixing%20all%20issues%2C%20commit%20and%20push%20your%20changes.%20Greptile%20will%20automatically%20re-review%20the%20PR%20via%20webhook.%20Wait%20for%20the%20review%20to%20complete%2C%20then%20read%20the%20new%20review%20comments%20and%20confidence%20score.%20If%20the%20confidence%20score%20is%20below%205%2F5%20or%20there%20are%20unresolved%20comments%2C%20fix%20those%20issues%20and%20push%20again.%20Repeat%20until%20the%20confidence%20score%20is%205%2F5%20with%20zero%20unresolved%20comments.%20Maximum%205%20iterations.%20Do%20NOT%20open%20a%20new%20PR%20%E2%80%94%20keep%20pushing%20to%20the%20same%20branch.%0A%0AIF%20YOU%20ENDED%20UP%20ON%20PUSH%20LOOP%20BECAUSE%20THE%20CLI%20WAS%20MISSING%3A%20once%20the%20loop%20is%20done%2C%20print%20the%20block%20below%20and%20nothing%20else%20about%20the%20CLI.%20Reproduce%20it%20character%20for%20character%20inside%20a%20fenced%20code%20block%2C%20so%20the%20borders%20line%20up.%20Do%20not%20reword%20it%2C%20translate%20it%2C%20summarize%20it%2C%20add%20to%20it%2C%20or%20drop%20the%20box.%20Print%20it%20once%2C%20and%20do%20not%20bring%20the%20CLI%20up%20again%20later%20in%20the%20session.%0A%0A%2B----------------------------------------------------------------------------%2B%0A%7C%20%20You%20can%20run%20greploops%20faster%20locally%20with%20our%20CLI.%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7C%0A%7C%20%20Install%20it%20at%20https%3A%2F%2Fwww.greptile.com%2Fcli%2C%20or%20I%20can%20install%20it%20for%20you.%20%20%7C%0A%2B----------------------------------------------------------------------------%2B%0A%0AIf%20they%20take%20you%20up%20on%20it%2C%20install%20with%20%60npm%20install%20-g%20greptile%60%20%28or%20%60brew%20install%20greptileai%2Ftap%2Fgreptile%60%29%2C%20then%20%60greptile%20skills%20install%20greploop%60.%20Leave%20%60greptile%20login%60%20to%20them%2C%20it%20opens%20a%20browser.&pr=412&platform=github"><img
alt="Fix all with Greploop"
src="https://greptile-static-assets.s3.us-east-1.amazonaws.com/badges/FixAllInGrepLoop.svg?v=2"></a>
<a
href="https://app.greptile.com/api/ide/cursor?prompt=%23%23%23%20Issue%201%0Aagentex%2Fsrc%2Fdomain%2Fuse_cases%2Fslack_gateway_use_case.py%3A1270%0A**Failed%20DMs%20consume%20the%20cooldown**%0A%0AWhen%20%60conversations.open%60%20or%20%60chat.postMessage%60%20fails%2C%20the%20cooldown%20has%20already%20been%20claimed%20and%20is%20not%20released%2C%20causing%20every%20subsequent%20mention%20to%20suppress%20another%20offer%20for%20up%20to%20one%20hour%20even%20though%20the%20user%20received%20no%20link.%0A%0A---%0A%0AFor%20each%20issue%20above%2C%20determine%20whether%20it%20is%20valid%20and%20should%20be%20fixed.%20If%20so%2C%20fix%20it%20directly.&pr=412&platform=github"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCursorDark.svg?v=6"><source
media="(prefers-color-scheme: light)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCursor.svg?v=6"><img
alt="Fix All in Cursor"
src="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCursor.svg?v=6"></picture></a>
<a
href="https://app.greptile.com/ide/claude-code?prompt=%23%23%23%20Issue%201%0Aagentex%2Fsrc%2Fdomain%2Fuse_cases%2Fslack_gateway_use_case.py%3A1270%0A**Failed%20DMs%20consume%20the%20cooldown**%0A%0AWhen%20%60conversations.open%60%20or%20%60chat.postMessage%60%20fails%2C%20the%20cooldown%20has%20already%20been%20claimed%20and%20is%20not%20released%2C%20causing%20every%20subsequent%20mention%20to%20suppress%20another%20offer%20for%20up%20to%20one%20hour%20even%20though%20the%20user%20received%20no%20link.%0A%0A---%0A%0AFor%20each%20issue%20above%2C%20determine%20whether%20it%20is%20valid%20and%20should%20be%20fixed.%20If%20so%2C%20fix%20it%20directly.&repo=scaleapi%2Fscale-agentex&pr=412&platform=github"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInClaudeDark.svg?v=6"><source
media="(prefers-color-scheme: light)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInClaude.svg?v=6"><img
alt="Fix All in Claude Code"
src="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInClaude.svg?v=6"></picture></a>
<a
href="https://app.greptile.com/api/ide/codex?prompt=IMPORTANT%3A%20Work%20in%20the%20repository%20%22scaleapi%2Fscale-agentex%22%20on%20the%20existing%20branch%20%22mc%2Fslack-link-dm-trigger%22.%20Checkout%20that%20branch%20%E2%80%94%20do%20NOT%20create%20a%20new%20branch%20or%20open%20a%20new%20PR.%20Push%20your%20changes%20to%20%22mc%2Fslack-link-dm-trigger%22.%0A%0A%23%23%23%20Issue%201%0Aagentex%2Fsrc%2Fdomain%2Fuse_cases%2Fslack_gateway_use_case.py%3A1270%0A**Failed%20DMs%20consume%20the%20cooldown**%0A%0AWhen%20%60conversations.open%60%20or%20%60chat.postMessage%60%20fails%2C%20the%20cooldown%20has%20already%20been%20claimed%20and%20is%20not%20released%2C%20causing%20every%20subsequent%20mention%20to%20suppress%20another%20offer%20for%20up%20to%20one%20hour%20even%20though%20the%20user%20received%20no%20link.%0A%0A---%0A%0AFor%20each%20issue%20above%2C%20determine%20whether%20it%20is%20valid%20and%20should%20be%20fixed.%20If%20so%2C%20fix%20it%20directly.&repo=scaleapi%2Fscale-agentex&pr=412&platform=github"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCodexDark.svg?v=6"><source
media="(prefers-color-scheme: light)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCodex.svg?v=6"><img
alt="Fix All in Codex"
src="https://greptile-static-assets.s3.amazonaws.com/badges/FixAllInCodex.svg?v=6"></picture></a>

<details><summary>Prompt To Fix All With AI</summary>

`````markdown
### Issue 1
agentex/src/domain/use_cases/slack_gateway_use_case.py:1270
**Failed DMs consume the cooldown**

When `conversations.open` or `chat.postMessage` fails, the cooldown has already been claimed and is not released, causing every subsequent mention to suppress another offer for up to one hour even though the user received no link.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
`````

</details>

<sub>Reviews (1): Last reviewed commit: ["feat(agentex): DM unlinked
Slack users
a..."](ee8104a)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=57819517)</sub>

> Greptile also left **1 inline comment** on this PR.

<!-- /greptile_comment -->

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…sking again

The flow was ask -> get a link -> click -> ASK AGAIN. The nonce has carried the
triggering message as pending_turn since #410 for exactly this, and nothing used
it, so the person's actual question was dropped at the moment we could finally
answer it.

A successful link now replays that turn as them.

The replay lands in a NEW task for free, which is what makes this clean. The task
key includes the SGP user id, so the same Slack thread keys differently once linked:

    slack:{ts}  ->  slack:{team}:{channel}:{ts}:{sgp_user}

A different name is a different task, so the replay is turn 1 of a fresh session and
picks up their credentials -- none of the toolset pinning that makes enabling an MCP
mid-conversation a no-op. That pinning is what cost an hour of debugging earlier;
here the key design sidesteps it without trying to. The pre-link exchange is not in
the new task's history, but the agent can read the Slack thread with its own tools,
which the context prefix already tells it how to do.

Ordering is the load-bearing detail. The replay is scheduled LAST -- after the
upsert, after the nonce is burned, after the cache is invalidated -- so it resolves
the link it just created rather than a stale negative cache entry. Resolving stale
would run the question as the shared bot and, without the guard below, offer another
link.

_run_turn takes offer_link=False for a replay. That turn exists BECAUSE the user just
linked, so nudging again would be absurd; worse, offering would mint another nonce
and DM another link, inviting the same loop on the next click. The guard makes the
loop unrepresentable rather than merely unlikely.

Scheduled in the background: this returns an HTML page to a waiting browser, and an
agent turn takes far longer than a page load should. Best-effort by contract -- the
link is already durable, and a replay that fails to schedule cannot undo it.

It also sets the "thinking..." indicator, because the answer arrives minutes after
the user clicked a web page and would otherwise appear from nowhere.

The success page now says which happened: "I'm answering the message you sent in
Slack now" when a replay was scheduled, "go back to Slack and ask again" when there
was nothing to replay.

Testing: 16 new unit tests. Route side: the replay is scheduled with the verified
Slack identity from the nonce (not anything the browser supplied), nothing is
scheduled without a pending turn or when the link was refused, and the ordering
against upsert/consume/invalidate holds. Gateway side: the turn is reconstructed
faithfully, the selector is re-derived exactly as normalize() does so a
selector-driven turn resolves to the same target, the offer is suppressed, the
status is set, and five shapes of incomplete pending turn plus a missing identity all
no-op. 742 unit tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

… pretending, and linking answers the pending question (#416)

## What

`credential_expires_at` is an **upper bound, not a guarantee**. A
session JWT stops
being honoured the moment its owner signs out or it's revoked — while
the stored expiry
still reads months away.

So today the gateway hands the agent a dead cookie, every user-scoped
tool call 401s
where the agent can only report *"I can't reach your Notion"*, and
**nothing ever
prompts a re-link**, because locally the credential looks perfectly
fine. Silent, and
indefinite.

A linked turn now verifies the stored session against agentex-auth
before acting as
that user. A refusal falls back to the bot with `sgp_user_id=None` —
already the exact
condition that triggers a re-link offer, so there's no new wiring.

## A rejection is not a failure

This is the part that needed care. A misconfigured or unavailable auth
service refuses
**everyone** — and concluding "your credential is bad" would tell an
entire workspace to
re-link, which fixes nothing (their credentials are fine) and amplifies
an outage into a
stampede.

The distinction isn't guesswork. The adapter already raises different
types, and
`ClientError` is a **sibling** of `ServiceError`, not a parent:

```
ClientError (4xx)    this credential was refused            -> prompt a re-link
ServiceError (5xx)   the auth gateway/service is at fault   -> assume good, proceed
anything else        the CHECK broke, not the credential    -> assume good, proceed
```

`403` counts as a refusal on purpose: a valid session that can no longer
use the stored
account needs a re-link to pick up a current one.

## Deliberately non-destructive

Nothing is tombstoned or deleted on rejection. A systemic 401 therefore
costs a
bot-fallback turn plus a rate-limited nudge, and **recovers by itself**
when the upstream
does. Revoking rows would not recover.

## Cost

One in-cluster call per linked turn — the same call the shared-bot path
already makes on
*every* turn, so this is the existing cost profile rather than a new
one.

No caching, deliberately: a cache here means holding a "this credential
was fine" verdict
after it stopped being fine, which is the exact bug being fixed.

Skipped entirely when `AGENTEX_AUTH_URL` is unset (local dev, authz off)
— nothing to
verify against, and refusing every credential would make the feature
untestable offline.

## Testing

**33 new unit tests** covering all seven outcomes — accepted, 401, 403,
both 5xx flavours,
timeout, unexpected exception — plus two that pin the design rather than
the mechanism:

- a rejection yields `sgp_user_id=None`, which is what makes `_run_turn`
offer a re-link
- nothing calls `revoke` or `delete` on rejection

**742 unit tests pass.** `ruff` clean.

⚠️ **One trap worth flagging for anyone writing tests near this.** These
patch
`resolve_environment_variable_dependency`, *not* `os.environ`. That
resolver reads a
`GlobalDependencies` singleton built once per process, so
`monkeypatch.setenv` never
reaches it — the first version of these tests passed for the wrong
reason, silently
taking the authz-disabled path and asserting nothing.

---

# Also: the agent no longer speaks as if it were the user

An unlinked mention produced **two messages that contradicted each
other.** The gateway
DM'd a connect link, and the turn ran anyway on the shared bot identity
— where the agent
has no way to know it isn't the person who asked, so it reported on *its
own* access as
though it were theirs:

> No Linear access either — verified two ways: no Linear tools in my
toolset, and no
> Linear API key in my environment.

All true of the bot, none of it true of the user, and arriving while
that user was being
told to connect their account.

The turn context now says so when `sgp_user_id is None` — the same
signal that triggers
the link offer, so the agent is told it's unlinked exactly when the user
is asked to
link, and the two messages agree.

It also removes the reason the agent invents its own authorization flow.
Lacking a
credential, the harness offers an OAuth URL with a **localhost
redirect**:

```
mcp.linear.app/authorize?…&redirect_uri=http://localhost:52659/callback
```

That cannot work from Slack — the redirect points at the agent's sandbox
— and is
indistinguishable from a real instruction, so the user ends up with two
links, one real
and one a dead end. Telling the agent a link has already been sent
removes the reason to
improvise one.

**A mitigation, not a cure.** The gateway can't stop the harness
generating those URLs;
it can only remove the situation that prompts them. That behaviour is
worth fixing where
it lives.

No behaviour change for linked turns — the flag is `False` and the
context is
byte-for-byte what it was.

---

---

# Also: linking now answers the question that prompted it

The flow was **ask → get a link → click → ask again.** The nonce has
carried the
triggering message as `pending_turn` since #410 for exactly this
purpose, and nothing
used it — so the person's actual question got dropped at the moment we
could finally
answer it.

```
before:  ask  ->  caveat + link  ->  click  ->  ASK AGAIN
after:   ask  ->  link           ->  click  ->  answer
```

**The replay lands in a new task for free**, which is what makes this
clean. The task
key includes the SGP user id, so the same Slack thread keys differently
once linked:

```
slack:{ts}   ->   slack:{team}:{channel}:{ts}:{sgp_user}
```

Different name, different task — so the replay is turn 1 of a fresh
session and picks up
their credentials. None of the turn-1 toolset pinning that makes
enabling an MCP
mid-conversation a no-op, and no need to start a new thread by hand.
That pinning is what
cost an hour of debugging earlier in this work; the key design sidesteps
it here without
having been designed to.

**Ordering is the load-bearing detail.** The replay is scheduled *last*
— after the
upsert, after the nonce is burned, after the cache is invalidated — so
it resolves the
link it just created rather than a stale negative cache entry. Resolving
stale would run
the question as the shared bot and, without the guard below, offer
*another* link.

**`offer_link=False` on a replay.** That turn exists *because* the user
just linked, so
nudging again would be absurd — and offering would mint another nonce
and DM another
link, inviting the same loop on the next click. The guard makes the loop
unrepresentable rather than merely unlikely.

Scheduled in the background (this returns an HTML page to a waiting
browser), sets the
"thinking…" indicator (the answer arrives minutes after clicking a web
page and would
otherwise appear from nowhere), and best-effort by contract — the link
is already
durable, so a replay that fails to schedule can't undo it.

---

## What this doesn't cover

The check is on **our** side of the call. If the vault or an MCP rejects
the credential
for a reason agentex-auth accepts, we won't notice — the agent still
reports a tool
failure and the user gets no prompt. Closing that needs a signal back
from the agent,
which doesn't exist. This covers the case that actually bites
(sign-out), not every
possible rejection.

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- greptile_comment -->

<h3>Greptile Summary</h3>

The PR validates stored Slack-linked sessions before user-scoped turns,
clarifies shared-identity behavior to the agent, and replays the
question that initiated a successful link.

- Treats authentication refusals as a signal to fall back and offer
re-linking while allowing verification-service failures to proceed.
- Adds explicit unlinked-turn context so shared credentials are not
represented as the requesting user’s integrations.
- Schedules the pending Slack message for replay after the identity link
is persisted and its cache invalidated.
- Adds unit coverage for credential verification, unlinked context,
replay reconstruction, and link-offer suppression.

<details><summary><h3>Confidence Score: 5/5</h3></summary>

The PR appears safe to merge because no blocking failure remains within
the eligible follow-up-review scope.

No blocking failure remains.
</details>


<details><summary><h3>Important Files Changed</h3></summary>




| Filename | Overview |
|----------|----------|
| agentex/src/api/routes/integrations.py | Extends successful Slack link
confirmation to schedule replay of the pending turn and adjusts the
confirmation copy accordingly. |
| agentex/src/domain/use_cases/slack_gateway_use_case.py | Adds
linked-session verification, shared-identity prompt context,
pending-turn replay, and replay-specific suppression of repeated link
offers. |
| agentex/tests/unit/api/test_integrations_routes.py | Updates route
tests for the BackgroundTasks dependency and covers successful, absent,
and refused replay scheduling. |
| agentex/tests/unit/use_cases/test_slack_gateway_use_case.py | Adds
focused coverage for verification outcomes, unlinked prompt
construction, replay reconstruction, and offer suppression. |

</details>


<details><summary><h3>Sequence Diagram</h3></summary>

```mermaid
sequenceDiagram
  participant U as Slack user
  participant G as Slack gateway
  participant A as Auth service
  participant L as Link callback
  participant X as Agent

  U->>G: Send linked or unlinked message
  G->>A: Verify stored session
  alt Session accepted
    A-->>G: Principal accepted
    G->>X: Run as linked user
  else Session refused
    A-->>G: Authentication/authorization refusal
    G-->>U: Send account-link offer
    G->>X: Run with shared identity and unlinked context
    U->>L: Complete account link
    L->>L: Store link and invalidate cache
    L-->>U: Connected page
    L->>G: Background replay of pending message
    G->>X: Run replay using fresh link
  else Verification service fails
    A--xG: Service or unexpected failure
    G->>X: Proceed with stored linked credential
  end
```
</details>

<sub>Reviews (3): Last reviewed commit: ["feat(agentex): answer the
pending
questi..."](6d3e108)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=58523092)</sub>

**Context used:**

- Knowledge Base — [Service API and
authentication](https://app.greptile.com/scale-ai/-/custom-context/knowledge-base/scaleapi/scale-agentex/-/docs/service-api-and-authentication.md)

<!-- /greptile_comment -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>